Date: Thu, 4 Mar 93 04:30:02 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 4#58 

To: packet-radio 


Packet-Radio Digest Thu, 4 Mar 93 Volume 93 : Issue 58 


Today's Topics: 
Fo-20 TNC Settings? (4 msgs) 
FT726R 
Help on NOS mail to AX.25 (PLEASE!) 
What happened to MIR? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Wed, 3 Mar 1993 15:57:52 GMT 

From: usc!howland.reston.ans.net!gatech! kd4nc!ke4zv! gary@network.UCSD.EDU 
Subject: Fo-20 TNC Settings? 

To: packet-radio@ucsd.edu 


In article <1180@arrl.org> lhurder@arrl.org (Luck Hurder KY1T) writes: 
>In rec.radio.amateur.packet, gary@ke4zv.uucp (Gary Coffman) writes: 
>> 

>>Here piggy piggy piggy. This is a poor channel sharing strategy. 
>>It maximizes xyour*x chances at the expense of everyone else. If 
>>everyone does it, it minimizes everyone's chances of using the 
>>satellite. 

>> 

> 

>That would absolutely be true on terrestrial links, of course. 

> 

>But it's also equally UNtrue on the F020 satellite, Gary. In the 
>whole Hartford area, I'm only likely to interfere with one fellow 
>-- my boss -- and in that EXTREMELY unlikely event, one of us 


>simply does the kind, Amateur Radio, thing - and moves to one of 
>the other uplink channels. 


Actually your signal is competing with everyone else in the satellite's 
footprint, not just the local area. That's a circle at least a couple 
hundred km in diameter. Just because you can't hear them doesn't mean 
the satellite couldn't have if not for your repeated transmissions. 
The satellite is a classic exposed terminal. It hears many competing 
stations from outside your local receiving range. The only way you 
know they are there is when the satellite fails to respond to your 
packets on a regular basis. You can all set piggy parameters and 

make all your lives miserable, you can play power wars and make 

some of your lives miserable, or you can set up as good as possible 
RF transceive conditions and friendly parameters and all enjoy the 
satellite. 


>It's also untrue for another reason. FO20 is so wonderfully unknown 
>(in spite of our best efforts to create fun articles about it in QST!) 
>that there's hardly anybody on it at any given time. 


Now that's a better reason. If you have nearly exclusive channel 
availability to the satellite, you can use piggy parameters to 
compensate for a bad RF path without harming anyone else's access 
to the bird. Still, having a better RF path will increase your 
thruput, so it's worth worrying about in any case. 


Don't take this as a personal flame. I just want to make people 
aware of the potential interference problems you run into with 
an exposed terminal like a satellite. If everyone uses piggy 
parameters, not many people can effectively use the satellite. 
If everyone makes nice, the satellite will be usable by more 
people. 


We once had a terrestrial exposed terminal here in North Georgia. 
It was a mountaintop site on 145.01 MHz. There were times when 

it was held off from digipeating for as long as 15 minutes because 
of the excessive number of stations trying desparately to use 

it with short holdoff and fixed persistance. Very few of the 

users could hear each other direct so they were always complaining 
that the digi was broken. Well it wasn't. The site owner brought 
in an audio trace log and let it play during a packet meeting. It 
almost never stopped squalling during the two hour meeting. That 
certainly opened a few eyes. Using longer Dwait values, and ultimately 
using p-persistent exponential backoff at most user stations made 
the channel usable again until growth ultimately overwhelmed it 
totally. Finally, smaller coverage, backbone linked, sites have 
solved the problem for now. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: 2 Mar 93 10:38:02 EDT 

From: saimiri.primate.wisc.edu!sdd.hp.com!ncr-sd!ncrcae!ncrhub2!ncrgw2!psinntp! 
arrl.org@ames.arpa 

Subject: Fo-20 TNC Settings? 

To: packet-radio@ucsd.edu 


In rec.radio.amateur.packet, tedwards@eng.umd.edu (Thomas Grant Edwards) writes: 
> 

>I can't even begin to imagine how ARSENE is going to work, given 

>the trouble I've had getting onto FO-20. Perhaps it will be 

>armed with something to automatically cut off someone who sends 

>more than 1 packet every 30 seconds or something like that based on 

>load. 

> 


Good point. Even so, I'm actively enjoying the prospect of setting 
up an ARSENE-gate for local HT-and-a-TNC users to thrash away on 
ARSENE. It should be quite a chuckle! 


I don't believe for a second that your difficulties with FO 20 are 
related in any way to others using it at the same time. On the other 
hand, I don't know WHAT the problem is, except to say that it works 
well for me. 


By the way, has anybody heard of a launch date for ARSENE? 


N 
| | | Deputy Manager, Field Services, ARRL. 
| |__| The ARRL Amateur Radio Emergency Service, the ARRL 
| uck | |urder National Traffic System, The Amateur Auxiliary to 
------ | | the FCC's Field Operations Bureau, the ARRL 
KYLT Field Organization and the ARRL Monitoring System. 


lhurder@arrl.org Prodigy - MGTS39A, BIX - ARRL, 
MCI Mail - RPALM, MCI Mail - "ARRL HQ", America On Line - "ARRL HQ" 
Compuserve - 70007,3373 (ARRL HQ) -- Genie ARRL.HQ 


Date: 2 Mar 93 10:24:57 EDT 

From: mvb.saic.com!unogate!news.service.uci.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com! 
ner-sd!ncrcae!ncrhub2!ncrgw2!psinntp!arrl.org@network.UCSD.EDU 

Subject: Fo-20 TNC Settings? 

To: packet-radio@ucsd.edu 


In rec.radio.amateur.packet, gary@ke4zv.uucp (Gary Coffman) writes: 
> 

>Here piggy piggy piggy. This is a poor channel sharing strategy. 
>It maximizes xyourx chances at the expense of everyone else. If 
>everyone does it, it minimizes everyone's chances of using the 
>satellite. 

> 


That would absolutely be true on terrestrial links, of course. 


But it's also equally UNtrue on the FO20 satellite, Gary. In the 
whole Hartford area, I'm only likely to interfere with one fellow 
-- my boss -- and in that EXTREMELY unlikely event, one of us 
simply does the kind, Amateur Radio, thing - and moves to one of 
the other uplink channels. 


It's also untrue for another reason. FO20 is so wonderfully unknown 
(in spite of our best efforts to create fun articles about it in QST!) 
that there's hardly anybody on it at any given time. 


Therefore, I stand by my assertion that cranking the FRack down 
to something otherwise-wierd like TWO is a logical thing to do. 


Besides, it works fine. And impacts on nobody. 


| | Deputy Manager, Field Services, ARRL. 
| | The ARRL Amateur Radio Emergency Service, the ARRL 
| | urder National Traffic System, The Amateur Auxiliary to 
------ | | the FCC's Field Operations Bureau, the ARRL 
KYLT Field Organization and the ARRL Monitoring System. 
lhurder@arrl.org Prodigy - MGTS39A, BIX - ARRL, 
MCI Mail - RPALM, MCI Mail - "ARRL HQ", America On Line - "ARRL HQ" 
Compuserve - 70007,3373 (ARRL HQ) -- Genie ARRL.HQ 


Date: 4 Mar 1993 02:45:39 GMT 


From: ucsd.edu! brian@network.UCSD.EDU 
Subject: Fo-20 TNC Settings? 
To: packet-radio@ucsd.edu 


gary@ke4zv.UUCP (Gary Coffman) writes: 

>We once had a terrestrial exposed terminal here in North Georgia. 
>... The site owner brought 

>in an audio trace log and let it play during a packet meeting. It 
>almost never stopped squalling during the two hour meeting. 


Think how much better that would have worked if it had been a "full 
duplex" packet repeater! 


Digipeaters have to go away. 


I've run FDX packet over the satellite; it's great! 
- Brian 


Date: 3 Mar 93 19:41:19 GMT 

From: agate! howland.reston.ans.net!gatech!pitt.edu!dsinc!ub! 
galileo.cc.rochester.edu!uhura.cc.rochester.edu!dnlg_ltd@ames.arpa 
Subject: FT726R 

To: packet-radio@ucsd.edu 


We have a 6m module for this radio. We would like to get a 440-450 MHZ 
module if possible. We will consider any offer as well as an even swap. 


Please reply to: 
Dan (N2PRC) dnlg_ ltd@uhura.cc.rochester.edu or 
Brian (KB4JP0) bstp_ltd@uhura.cc.rochester.edu 


Date: 3 Mar 93 19:29:30 MDT 

From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!caen!hellgate.utah.edu!cc.usu.edu! 
sltmw@network.UCSD.EDU 

Subject: Help on NOS mail to AX.25 (PLEASE!) 

To: packet-radio@ucsd.edu 


In article <1993Mar1.120843.64646@cc.usu.edu>, I write: 

> Well, this is a beaten to death problem, but I can't for the life of me get my 
> WJ7J 1.07b, BBS to recieve and forward mail...Here are copies of my REWRITE, 

> ALIAS, and FORWARD.BBS files 

> 


[misc. stuff deleted] 


I figured out the problem, the ALIAS, and REWRITE files can only have one space 
between the commands.... 


Sater KE ila The Ex-Royal Gigolo of the House of Norwedia--------------------- 


/ | "I drank WHAT?" -Socrates 

\ uper |)an |-|olmes | "I love the smell of Napalm in the morning" -Big Duke: 

/ 'N7NKR' | Apocalypse Now 
I'net: sltmw@cc.usu.edu sltmw@cache.declab.usu.edu Bitnet: sltmw@usu.bitnet 
ghazexsrcwtdceterfygstgyiy <--------- sorry, just wiping the puke off my keyboard 


Date: 3 Mar 93 09:32:38 EST 

From: titan.ksc.nasa.gov!k4dii.ksc.nasa.gov!user@ames.arpa 
Subject: What happened to MIR? 

To: packet-radio@ucsd.edu 


I've had a TNC sitting on 145.550 MHz for several days now, and haven't 
heard a peep out of MIR. Since yesterday, there were a couple of 
nearly-overhead passes. Did they change frequency? 


73, Fred, K4DII 


fred-mckenzie@ksc.nasa. gov 


Date: 3 Mar 93 20:20:17 GMT 

From: ogicse!uwm.edu! zaphod.mps.ohio-state.edu!darwin.sura.net!mojo.eng.umd.edu! 
tedwards@network.UCSD.EDU 

To: packet-radio@ucsd.edu 


References <1993Feb28.151214.11664@ke4zv.uucp>, <ImruloINNhOm@mojo.eng.umd.edu>, 
<1993Mar3 .162014.3557@ke4zv.uucp> 
Subject : Re: Fo-20 TNC Settings? 


In article <1993Mar3.162014.3557@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) 
writes: 

>In article <1ImruloINNhOm@mojo.eng.umd.edu> tedwards@eng.umd.edu (Thomas Grant 
Edwards) writes: 


>>I can't even begin to imagine how ARSENE is going to work, given 
>>the trouble I've had getting onto FO-20. Perhaps it will be 
>>armed with something to automatically cut off someone who sends 


>>more than 1 packet every 30 seconds or something like that based on 
>>load. 


>Some AMSAT thinkers have suggested using master stations and polling 
>in a quasi-token ring configuration in order to manage users on 
>ARSENE. That has a chance of working if everyone cooperates. But it 
>only takes one or two loud piggies to spoil it for everyone. 


I think the biggest problem with any 

kind of a token ring situation is that stations will be added/dropped 
from the satellite footprint all this time, and if we too wait long for 
a station to pick up it's token, and that station is no longer in range, 
things will slow down rapidly. Still, if the max wait time is small 
(say 1-2 seconds) this shouldn't be too bad. Could you mention some 
details about how this might work? 


Another approach I thought up was having the digipeater sat send out 
packets which said how many users were on, and that you would have a 
smart terminal program which would grab these and set the TNC 
parameters to apropriate values. If we wanted to be a little elitist 
about it, the terminal program would tack on a special token to each 
uplinked packet which indicated that the special terminal program 

was in use, or maybe not only that but that it also recognized properly 
how many users were on, and that packets without those tokens would be 
dropped, hopefully keeping users without the adaptive terminal program 
from accessing the sat. Of course, this would be annoying. Then again, 
it would also be annoying to have a sat digipeater which is uselessly 
jammed by a million users who keep sending packet after packet without 
waiting. Anyway, since ARSENE isn't smart enough, we'll save this 
method for later sat digis. 


-Thomas N3HAU 


Date: Wed, 3 Mar 1993 16:20:14 GMT 
From: usc!howland.reston.ans.net!gatech! kd4nc!ke4zv! gary@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <1169@arrl.org>, <1993Feb28.151214.11664@ke4zv.uucp>, 
<imruloINNhOm@mojo.eng.umd.edu> 

Reply-To : gary@ke4zv.UUCP (Gary Coffman) 

Subject : Re: Fo-20 TNC Settings? 


In article <1ImruloINNhOm@mojo.eng.umd.edu> tedwards@eng.umd.edu (Thomas Grant 
Edwards) writes: 
>In article <1993Feb28.151214.11664@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) 


writes: 

>>A kinder gentler packeteer will set his frack so that it's longer 
>>than the longest possible roundtrip acknowledge time. Otherwise 
>>he can clobber others with great regularity. A truly considerate 
>>operator will use P-persistant backoff and spend his time trying 
>>to improve his RF capabilities, both up and down so he'll have 
>>fewer garbage frames. 

> 

>I can't even begin to imagine how ARSENE is going to work, given 
>the trouble I've had getting onto FO-20. Perhaps it will be 
>armed with something to automatically cut off someone who sends 
>more than 1 packet every 30 seconds or something like that based on 
>load. 


Unfortunately it's not that smart Thomas. That doesn't really solve 
the piggy problem anyway since stations will continue to send their 
repetitive packets effectively jamming the channel for others. It's 
what the satellite's receiver hears, not what it's digits decode 
that determines the usability of the channel. 


Some AMSAT thinkers have suggested using master stations and polling 
in a quasi-token ring configuration in order to manage users on 
ARSENE. That has a chance of working if everyone cooperates. But it 
only takes one or two loud piggies to spoil it for everyone. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


End of Packet-Radio Digest V93 #58 
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